該選擇 API 還是框架呢？

第1天先來輕鬆聊聊。

在生成式 AI 應用的開發過程中，我們可能會面臨一個關鍵的選擇：應該選擇直接使用 API （例如OpenAI的API）還是採用一個完整的框架（例如LangChain或Semantic Kernel）來實現生成式AI應用？這個問題我個人認為不單是從技術層面出發的考量，而更可能涉及到開發效率、市場競爭(例如想快速推出功能)、靈活性以及未來維護的便利性等。如果你正在開發的是面向市場的產品，那麼要考慮可能是如何快速從：點子 -> POC -> MVP 產品（最小可行性產品），以驗證商模。因此該選擇 API 還是框架，需要理解這二種方式的差異，以適合不同的需求場景。並且也可能是混合使用，或是中途轉換，我也看過或聽過一開始使用框架到最後決定放棄使用框架的案例。

我並不打算直接做2分法來告訴你，應該使用API還是應該使用框架，我只就我個人的經驗分享一些我的看法，可能是對的也很有可能是錯的，但也許有一點點參考價值？(也許....)

API 的優勢與限制

API 通常由各種 AI 模型提供商提供，例如 OpenAI、Google AI 等，這些API 通常是最簡單且又直接能與大規模語言模型（LLM）進行互動的方式。它的優點是靈活性最高，開發者可以完全掌控模型的每一個細節，只要API有開出對應的參數，你就能操控。但是，這種方式可能需要較多的時間去處理一些更底層的技術細節，例如：串接各種不同模型的 API(例如：OpenAI ChatGPT與Google Gemini的API肯定細節不一樣)、模型參數的設置、例外的處理、優化性能等。而當面對更大規模的需求或功能時，開發者就需要花費更額外的心力來管理模型的狀態、處理多次呼叫上下文關聯性。也就可能會增加整體專案的複雜度和開發成本。而根據 AI 模型提供商推出新的模型版本，API參數或版本也很有機會會變更。

框架的優勢與限制

與 API 相比，採用框架的開發方式則展現在開發效率和簡化流程。框架像是 LangChain 或 Semantic Kernel，這些工具通常會為開發者提供了大量常見的預設功能與封裝，讓開發者能夠快速上手，並專注於商業邏輯的實作，而不是陷於模型調用的技術細節泥沼中。

以 Semantic Kernel 為例，包含了許多內建功能，例如對話記憶、自動模型調用、工具裝載甚至到AI Agent等，這些功能能夠幫助開發者在短時間內實現生成式 AI 應用，此外，這一類的框架通常不會鎖定在特定的模型，而是會提供可能串接各種主流模型(無論是雲端或地端)，以及整合市場主流需求，例如RAG應用。

這類框架的便捷性特別適合需要快速開發原型(POC)、MVP 產品（最小可行性產品）或是大規模應用的情境。例如，希望在短時間內建立一個生成式 AI 聊天機器人，並且希望能自動處理對話的上下文記憶，選擇 Semantic Kernel 這樣的框架會讓你省去許多繁瑣的基礎鋪陳的設置工作，而直接專注於應用的核心功能開發。對於現在生成式AI快速變化的時程，具有一定的優勢。

然而使用框架並不是沒有缺點，框架同樣會面臨到版本快速變化的情況，通常比模型推出都還要快，每週…每月更新幾乎是常態，主因也是因為需求多，社群力量也大，因此框架內部架構的調整，配合AI模型的新功能調整，方法名稱的變更，都是過去使用框架比較少見的更動頻率。並且有時候框架本身相依的套件版本太混亂或是框架本身抽象化太多，以致於也會導致學習曲線太陡峭，或是面對客製想要調整但卻改不動的情況。

該如何選擇

PS：這一段是我個人的看法，看看就好，不見得正確，也許有我沒考慮到或沒看到的場景。

那麼，在兩者之間該如何選擇呢？我個人認為這取決於你的專案需求和開發目標。如果你需要高度的靈活性與自訂性，並且你有足夠的時間和資源來管理所有的技術細節，API 可能是更好的選擇。你可以完全掌控每一個細節部分，確保能夠滿足你的需求或符合你的應用架構。

反之，如果你希望快速開發一個生成式 AI 應用，並且更專注於商業邏輯和應用的實際效果，那麼選擇一個框架可能會更有效率。Semantic Kernel 提供了許多的預設功能，能夠快速上手，並且可以輕鬆對應生成式 AI 應用開發中的常見場景。

在接下來的挑戰文裡，我會從入門開始到深入的介紹 Semantic Kernel 的功能和實際應用，並且示範如何使用這個框架進行生成式應用的開發，希望可以在零庫存的情況下挑戰成功(哈)。